home *** CD-ROM | disk | FTP | other *** search
/ Nebula 2 / Nebula Two.iso / SourceCode / MiscKit1.7.1 / MiscKitArchive.mbox / mbox / 000108_yackd@oregon.et.byu.edu_Wed Feb 2 14:53 MST 1994.msg < prev    next >
Internet Message Format  |  1994-10-30  |  6KB
  1. Received: from yvax.byu.edu by maine.et.byu.edu; Wed, 2 Feb 1994 14:53:24 -0700
  2. Return-Path: <yackd@oregon.et.byu.edu>
  3. Received: from DIRECTORY-DAEMON by yvax.byu.edu (PMDF V4.3-3 #4169)
  4.  id <01H8EWWLWSTS019YM1@yvax.byu.edu>; Wed, 2 Feb 1994 14:53:05 MST
  5. Received: from alaska.et.byu.edu by yvax.byu.edu (PMDF V4.3-3 #4169)
  6.  id <01H8EWW5IY9C8Y4ZOD@yvax.byu.edu>; Wed, 2 Feb 1994 14:52:42 MST
  7. Received: from yvax.byu.edu by alaska.et.byu.edu; Wed, 2 Feb 1994 14:51:12 -0700
  8. Received: from DIRECTORY-DAEMON by yvax.byu.edu (PMDF V4.3-3 #4169)
  9.  id <01H8EWTQSZ8W019YM1@yvax.byu.edu>; Wed, 2 Feb 1994 14:50:46 MST
  10. Received: from oregon.et.byu.edu by yvax.byu.edu (PMDF V4.3-3 #4169)
  11.  id <01H8EWTJH2V48Y4YH7@yvax.byu.edu>; Wed, 2 Feb 1994 14:50:35 MST
  12. Received: by oregon.et.byu.edu; Wed, 2 Feb 1994 14:50:28 -0700
  13. Date: Wed, 02 Feb 1994 14:50:28 -0700
  14. From: yackd@oregon.et.byu.edu (Don Yacktman)
  15. Subject: Re: More object ideas
  16. To: misckit@byu.edu
  17. Message-Id: <9402022150.AA04661@oregon.et.byu.edu>
  18. Content-Transfer-Encoding: 7BIT
  19. Status: RO
  20.  
  21.  
  22.  
  23. Ah, very interesting.  I like these ideas a lot.
  24.  
  25. Let me make a few comments.  In the past 48 hours
  26. there has been a flood of submissions for the MiscKit.
  27. Some won't be completely ready for inclusion for
  28. about a month yet, and I will be doing a lot of
  29. work with the individuals involved to get everything
  30. prepared and ready for the kit.
  31.  
  32. Some of the objects include (1) a greatly enhanced
  33. subprocess class.  The donator doesn't have time to
  34. make the appropriate adjustments for the kit, so
  35. I will do that.  Give me two weeks and you'll have
  36. a bang up subprocess class.
  37.  
  38. (2) A generic document hadling framework like what
  39. we've been discussing.  Probably won't be ready for
  40. a month or so.  The goal is to have it within a
  41. month...the coding is basically done as I understand
  42. it.  If you were planning on doing code on this one
  43. contact me and I will try and set you up with the
  44. individual involved so that you can discuss architecture
  45. or any other considerations that you might think worth
  46. discussion.  Along with this document framework will
  47. be coming quite a few other object, but I'm not yet
  48. at liberty to say what they all are... :-)
  49.  
  50. (3) Major enhancements for the date/time class.
  51.  
  52. Anyway, on to the file and other stuff.
  53.  
  54. I really like these ideas; a generic file with
  55. appropriate subclasses could be very useful.  The
  56. trick here is that with OpenStep up and coming,
  57. we will have to be very careful that only certain
  58. subclasses or categories introduce OS dependencies.
  59.  
  60. Also, the interface on the chmod, etc. commands
  61. seems more like something that should have to
  62. do with the File objects, and NOT a subclass of
  63. subprocess/UNIX objects.  I say this because it
  64. is natural to think of file protections as an
  65. attribute of a file...so you'd send a message to
  66. the file object to change them.  The "ls" command
  67. would be an attribute query for the directory subclass
  68. of a file object.  Oh, and I _really_ think that it
  69. would be handy to have a subclass of the file object
  70. to deal with directories.  That would sure make
  71. surfing through a filesystem a cakewalk!
  72.  
  73. As to the logging, yes, both a "priority level"
  74. _and_ a mask would be useful.  I'm more in favor
  75. of a mask, though.  Priority levels are really
  76. limited in their flexibility.  Trouble is coming
  77. up with a reasonable set of masks that would cover
  78. enough situations.  So, there's no reason we cannot
  79. fall back on a priority level as well...supporting
  80. both would be easy enough.  And it's true that the
  81. current log file is really limited with what it
  82. can do.
  83.  
  84. So, looks like a generic file with appropriate
  85. subclasses would be a really good thing.  Certainly
  86. I'd also like to see a cover over pipes.  I've seen
  87. so many beginners forget to close one end of a pipe
  88. and then hang, and other similar goofs, that a class
  89. would be really useful there.
  90.  
  91. On the Mail and NeXTMail classes, don't bother writing
  92. them.  I am already doing this for a project that I am
  93. working on.  So these'll be in the MiscKit soon as it
  94. is.  In fact, I'm working on these tonight...  :-)
  95.  
  96. Once I get those mail objects into the kit, anyone
  97. like to do a MIMEMail object?  :-)
  98.  
  99. On the thread object...this would be extremely useful.
  100. I'd say that perhaps someone ought to look at that
  101. threadkit thing that was done a while back and see if
  102. that approach is the way to go...we can then build up
  103. a thread system based on that or something better, if
  104. we can think of a better way.  A thread object would
  105. make threaded apps a lot less scary to write, though,
  106. and that would be really good.  I'd like to see threading
  107. used more often under NS...
  108.  
  109. Oh, and I almost forgot.  Along with my Mail objects
  110. will come a generic template filling object as well.
  111. I had to use something like this a while back where
  112. I was extending VHDL (VLSI hardware desc. lang.) and
  113. adding new constructs.  The new constructs were
  114. basically "smart templates" so I'd parse the new
  115. command and use the parameters to generate masses of
  116. VHDL code based upon smart templates.  I'm trying to
  117. move this technology from C to ObjC in a nice way,
  118. and when I finish you'll have MiscTemplates, along
  119. with some helper objects, and probably a top-level
  120. object that can use the templates to merge records
  121. into templates, or other fun things...  :-)
  122.  
  123. Anyway, I thought I ought to mention those new
  124. objects that are coming in before anyone gets too
  125. deep into coding anything on similar objects.  Still
  126. no submission of a file class with appropriate
  127. subclasses, though, so who wants to do that one?
  128. Speak up now...and there's nothing wrong with putting
  129. together a "committee" to work together on it.  :-)
  130. I'd like to listen in on the development and perhaps
  131. make a few suggestions, but I'm already going to
  132. be MiscSwamped for the next month dealing with this
  133. current flood of objects.  (Remembering that I have
  134. "real world" work to get done in addition.  :-)   )
  135.  
  136. Well, who's our file handling guru gonna be, then?
  137.  
  138. Later,
  139. -don
  140.  
  141.  
  142. (PS:  more objects:  Sean Luke's sound meters and other
  143. stuff is almost ready.  Looking real nice.  He's even
  144. got a little example app that sits there and lights up
  145. whenever there's noise in the room.  Rather unnerving.)
  146.  
  147.